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FOREWORD 

1. The Committee on National Security Systems (CNSS), pursuant to its authority under 
"National Security Directive 42" (Reference a), is issuing this instruction to provide guidance for 
implementing CNSS Policy (CNSSP) No. 12, National Information Assurance Policy for Space 
Systems Used to Support National Security Missions (Reference b). 

2. The primary objective of this instruction is to help ensure space system planners, 
developers, operators, Authorizing Officials (AO), Security Controls Assessors (SCA), program 
managers/information system owners, and information assurance practitioners both understand 
and ensure information assurance (IA) is adequately integrated into all components of space 
systems falling under the purview of Reference b. 

3. Additional copies of this instruction may be obtained from the CNSS Secretariat or the 
CNSS website: http://www.cnss.gov . 

FOR THE NATIONAL MANAGER 



/s/ 

DEBORA A. PLUNKETT 
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National Information Assurance Instruction 
for Space Systems Used to Support National Security Missions 

SECTION I - PURPOSE 

1. This instruction provides guidance to Reference b. In addition to this instruction, 
Reference b must be consulted when identifying applicable space system requirements. 

2. This instruction helps ensure the success of missions that rely on use of space-based 
National Security Systems (NSS). It elaborates on how to appropriately integrate IA into the 
planning, development, design, launch, sustained operation, and deactivation of those space 
systems used to collect, generate, process, store, display, or transmit national security 
information, as well as any supporting or related national security systems. It also provides 
guidance to the AOs and SCAs for space systems with respect to their roles within the Risk 
Management Framework (RMF). 

SECTION II - AUTHORITY 

3. The authority to issue this instruction derives from National Security Directive 42, which 
outlines the roles and responsibilities for securing National Security Systems, consistent with 
applicable law, E.O. 12333, as amended, and other Presidential directives. Nothing in this 
Instruction shall alter or supersede the authorities of the Director of National Intelligence. 

SECTION III - SCOPE 

4. This instruction applies to all entities within the scope of Reference b. 

5. CNSS has jurisdiction over NSS only; therefore, non-NSS components are not under the 
purview of Reference b or this instruction. Where NSS space systems form a part of a system- 
of-systems which includes non-NSS systems components, the mission owner and AO for such 
system-of-systems must consider the impact of non-NSS systems or components in their end-to- 
end analysis of risks. When practical and necessary, non-NSS systems or components should be 
selected that have security controls consistent with this instruction. 
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SECTION IV - REQUIREMENTS 

6. General. 

a. AO Reviews. The AO or the AO's designee must be afforded the opportunity to 
participate and make recommendations regarding the adequacy of IA measures at all major 
design reviews and major program decision points. 

b. Experiments, Tests, and Demonstrations. NSS space systems/components used for 
experiments, tests, or technology/capability demonstrations are required to implement security 
controls per this instruction. Consideration should be given to using experiments, tests, or 
demonstrations as a test bed to concurrently evaluate new security controls. The selection and 
implementation of security controls and the subsequent residual risk analysis should be based on 
an appropriate operational use case in order to facilitate rapid transition of subject space 
system/components to operational use. If an operational use case is not applicable or cannot be 
defined, security controls to protect the space system/components and the data collected from 
exploitation or attack must be implemented. The AO and mission owner for any experiment, 
test, demonstration, or follow-on operational use must explicitly accept any risks of not fully 
complying with this instruction. 

c. Ground-based Security Controls. Special attention must be given to the fact that 
security requirements will vary for different components of a space system depending on when, 
where, and how those components are tested. Security controls needed for operations in flight 
may not be needed during system or component testing on the ground and vice versa. Data and 
physical connections not present or even possible while in flight will be established while the 
space system is on the ground. Security concerns with respect to physical access to the space 
system vary significantly depending on whether the system is in a pre- and post-launch 
environment. All the security implications of ground testing, storage, and transportation of space 
system components and of flight testing and operations must be addressed in the System Security 
Plan (SSP). The AO must approve the initial SSP and modifications to the SSP throughout the 
system's life cycle, ensuring the security control set is appropriate at each phase of the space 
system's life cycle and not solely for final operations in flight. The AO and program 
manager/information system owner must also ensure, through contracts, memoranda of 
agreement, service level agreements, etc., that appropriate security controls are applied to or by 
other systems and organizations when they logically or physically connect to or access the space 
system. 

d. Developmental Phase Security Concerns. The program manager/information system 
owner, in consultation with the information owner and mission owner, must develop a Program 
Protection Plan (PPP) describing how critical program information (CPI) and critical 
components (CC) will be protected in research, development, and acquisition of NSS space 
programs. The program manager/information system owner must present the PPP to the AO for 
review, who may forward the PPP to the acquisition milestone decision authority for approval. 
For any information system supporting research, development, and acquisition of NSS space 
systems, the PPP must be used to support the information categorization, information system 
categorization, and controls selection process or to support contract or service level agreement 
negotiations (e.g., cleared development contractor systems, commercial services, etc.). Program 
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managers/information system owners must request a Program Protection Implementation Plan 
from prime contractors to ensure protection requirements are passed to and implemented in all 
contractor locations. See Annex D for details on the PPP. 

e. National Security Agency (NSA) Guidance and Assistance. Programs must engage 
NSA early in the acquisition lifecycle (i.e., during requirements development) in order to 
minimize the cost and schedule risks associated with identifying security requirements late in the 
program and having to repeat parts of the security evaluation processes. Early engagement 
ensures the planned security architecture is consistent with NSA cryptographic security and 
information systems security guidance and restrictions. Early engagement will minimize 
potential cost and schedule risks associated with security requirements, cryptographic algorithm 
selection, cryptographic device selection, and the associated cryptographic evaluation processes. 1 

f. Crypto Bypass. 

1) Any capability designed into applicable space systems intended to bypass 
required cryptography (crypto bypass) requires approval by NSA prior to Critical Design 
Review. Crypto-bypass must be designed in a manner to minimize the probability of bypass 
activation due to malicious activity or failure of crypto bypass components. The program office 
must submit design information to the NSA early in the preliminary design phase and provide 
updates to the NSA as the design matures. 

2) The program office must include provisions for the NSA to review the 
implementation of operational systems such that NSA may verify no flaws are introduced. The 
program office must submit to the AO an artifact detailing any risks associated with using crypto 
bypass during system operations and test events. Risks associated with crypto-bypass are subject 
to AO acceptance. 

g. Body of Evidence (BOE). 

1) The program office must provide, upon request of the AO, any BOE artifact for 
the purpose of making authorization decisions. Typically, in addition to the security 
authorization package (i.e., SSP, Security Assessment Report (SAR), and Plan of Action and 
Milestones (POA&M)), the program office provides the following artifacts available to the AO: 

a) System Concept of Operations or Operational Concepts Description 

b) Authorization boundary diagram and description 

c) Hardware, software, and firmware baseline inventory 

d) Network diagram (showing all system components and internal/external 

connections) 



1 Vendors may engage NSA Information Assurance Directorate through the Information Assurance Business Affairs 
Office at: http://www.nsa.gOv/ia/contacts/index.shtml#bao . Government organizations should contact their 
Department, Agency, or Service's Client Advocates at the NSA IA Service Center. Further information can be 
found at: http://www.nsa.gOv/ia/contacts/index.shtml#niasc . 
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e) Data flow diagram (aligned with network diagrams to show high-level data 
flows across major system components and the accreditation boundary) 

f) Ports, protocols, and services (PPS) matrix (show all internal/external PPS; 
emphasize PPS crossing enclave boundaries) 

g) Cross domain ticket number(s) for all cross domain solutions (CDS) (need 
connection approval) 

h) Continuity of Operations Plan (or Business Continuity Plan, Disaster 
Recovery Plan, etc.) 

i) Backup and Restoration Plan 

j) Configuration Management Plan 

k) Memoranda of Agreement/Understanding and Service Level Agreements 

1) Risk Assessment Report 

2) The BOE artifacts are contained or referenced in the SSP, SAR, and POA&M. 
The program office must ensure the SCA has access to all artifacts in the BOE. Annex E 
provides an exemplar list of BOE artifacts, with the types and specificity varying depending on 
the size, complexity, and maturity of the system. 

7. Adequacy of Transmission Security (TRANSEC). A System TRANSEC Plan (STP) 
must be developed, coordinated, and maintained in accordance with the instructions contained in 
Annex F. The purpose of the STP is to ensure TRANSEC is appropriately addressed during 
space system developments and when space system services are leased or otherwise acquired. 
The STP provides the assigned AO concise documentation to support an adequacy review and 
adjudication of planned and/or implemented space system TRANSEC measures. 

8. Supply Chain Risk Management (SCRM). In accordance with CNSS Directive No. 
505, Supply Chain Risk Management (Reference c), organizations must follow SCRM, systems 
security engineering, and risk management best practices and use SCRM tools and resources for 
all NSS space systems. Due to a space system's harsh operating environment, inaccessible 
platforms, and generally higher monetary value, traditional SCRM processes, tools, and 
techniques may not be practical in all situations (e.g. use of on-orbit security configuration 
management tools, etc.). To help minimize residual vulnerabilities and potential defects or 
deficiencies, organizations must pay particular attention to designing and building space 
platforms to higher standards and assurances and must implement the following SCRM 
requirements: 

a. Conduct an analysis of mission criticality for all NSS space system components and 
functions in accordance with United States (U.S.) Government, Department, or Agency directive 
and guidance documents. 

b. Apply supply chain protection measures to all NSS space systems in accordance with 
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Reference c, CNSS Instruction (CNSSI) No. 1253, Security Categorization and Control 
Selection for National Security Systems (Reference d), and the Space Platform Overlay included 
in Reference d. 

c. Document all occurrences of suspect and confirmed counterfeit materiel in the 
appropriate reporting systems, to include the Government-Industry Data Exchange Program 
system. 

d. Identify potential incentives for commercial providers who voluntarily adopt NSS 
space system SCRM standards when commercially hosting NSS payloads and missions. 

9. Commercial Space System Services. IA requirements must be included in commercial 
contract-related documentation. Department/ Agency acquisition documentation must specify the 
following: 

a. What evidence the vendor must provide to give assurance they can comply with all 
IA requirements stipulated (e.g., at time of lease all security controls are implemented; system 
components are being maintained in the latest approved security configurations; IA-related plans, 
processes, and procedures are in place). 

b. IA requirements (threshold and objective) requested and also the associated proposal 
evaluation criteria. (NOTE: See Annex G for additional details on security controls to include.) 

c. How the vendor will provide immediate notification if any proposed or contracted IA- 
related design, security controls, configuration, processes, or procedures change at any time 
during contract competition or after contract award, respectively. 

d. What IA-related artifacts are required and the degree of artifact detail the vendor must 
provide at the time of evaluation for source selection. 

e. The ways in which the vendor will be subject to government validation and 
inspection of the vendor's IA posture at any time during the lease for service. 

f. The contract proposal evaluation plan, which will define the IA evaluation criteria. 

g. Requirements for IA monitoring and reporting (reference paragraph 14). 

h. The ways in which the vendor will support government- and program-led 
vulnerability and risk assessments, to include engagement with subject matter experts, access to 
documentation and proprietary information necessary to evaluate and mitigate residual risk. 

10. Hosted Payloads. 

a. Program managers/information system owners and AOs must identify and require 
implementation of additional security controls to mitigate the threats, vulnerabilities, and risks 
not readily identified during the hosting platform's requirements definition, design, and 
employment. If any security controls are not already implemented, they must be appropriately 
addressed by the respective program managers/information system owners to the satisfaction of 



5 



CNSSI No. 1200 



their respective AOs. 

b. When using hosting platforms, the government hosted payload organization must 
ensure IA strategies, SSPs, contracts, and memoranda of agreement address those requirements 
in Annex H. 

11. Risk Assessment Model. 

a. In accordance with CNSSP No. 22, AOs must perform risk assessments for space 
NSS in accordance with the guidance in National Institute of Standards and Technology (NIST) 
Special Publication (SP) 800-30, Guide for Conducting Risk Assessments (Reference e). 

b. AOs must perform and update risk assessments during each phase of a space system's 
life cycle. The life cycle of a space platform consists of the following phases: on-ground 
development, on-ground testing, pre-operational testing in space, operations in space, and 
decommissioning. As a minimum, risk assessments must: 

1) Identify system vulnerabilities and the associated known and expected threats 
likely over the lifetime of the system that can exploit these vulnerabilities. This will help support 
accurate selection, tailoring, and implementation of baseline security controls in accordance with 
Reference d. 

2) Identify and mitigate risks associated with the development phase of the lifecycle. 

3) Determine the residual risk following security control assessments. 

4) Determine, as part of continuous monitoring of authorized systems, the effect on 
risk due to changes to the system design or configuration, operational environment, operational 
concept or procedures, or threat sources' capability, intent, and targeting. 

5) Determine risks resulting from space platform components disposal actions or 
surviving reentry. 

c. The program/organization must identify the scope of the risk assessment in terms of 
organizational applicability, time frame supported, and architectural/technology considerations. 
For space platforms, the risk assessment must be performed as early as possible to identify the 
anticipated space environment-unique threats/vulnerabilities (imposing risk) requiring mitigation 
during the space platform's pre-launch development. Programs should develop space system 
architectures, technologies, and procedures that can mitigate latent vulnerabilities and adapt to 
emerging threats. 

d. The risk assessment must also consider that the information technology (IT) 
components control physical components of the space platform, and exploitation of any 
associated IT vulnerabilities can have immediate and catastrophic impacts to the space 
platform's functionality and supported mission. These unique risks must be identified in 
addition to all other types of risks. For examples of risks and lessons learned, consider similar 
non-space component control systems. 
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e. Appendices in Reference g provide exemplary tables, taxonomies, and inputs for risk 
factors applicable to typical IT systems. Some of that information does not apply to space 
systems, nor do the appendices consider the space-unique environment. Consequently, the AO 
(with the assistance of the SCA) must ensure risk assessments for space systems modify and 
augment the tables and taxonomies information to account for the space-unique environment 
affecting the risk factors. 

12. Flight Termination System (FTS). 

a. All links used for an FTS must implement mechanisms sufficient to ensure their 
availability, integrity, and confidentiality, as required by the mission. Launch systems using 
remotely commanded FTS must implement NSA-approved cryptography for that application. 

b. Autonomous FTS systems using Global Positioning System as an input must use 
Precise Positioning Service receivers. 

c. FTS hardware, software, and firmware must be developed, stored, and distributed in a 
manner that prevents inadvertent or intentional modification. 

d. See Annex I for additional guidance. 

13. Cyberspace Defense Service 

a. All NSS space systems and networks (to include the space, ground, launch, and user 
segments) and their associated critical support systems must be provided cyberspace defense 
services. 

b. Cyberspace defense services (whether government or commercial) must include: 
prepare, protect, detect, analyze, respond, and assess and adjust. Annex J provides descriptions 
of the services. For AO consideration and approval, responsible program managers/information 
system owners must provide in the system authorization package evidence of the service 
provider qualifications and ability to meet service execution and delivery. 

c. Cyberspace defense service activities must be coordinated as appropriate with 
network and space system operators, managers, owners, and users and with law enforcement, 
counterintelligence, and intelligence authorities. 

d. Traditional space platform and terminal suites provide Open Systems Interconnection 
(OSI) layer two and below functionality, so the corresponding cyberspace defense services are 
implemented on terrestrial networks. Space platforms providing OSI layer three and above 
functionality must have additional cyberspace defense services for the space platform. Whether 
or not these services can be provided remotely must be evaluated on a case-by-case basis; 
however, all on-orbit and terminal systems and subsystems must be provided an appropriate level 
of cyberspace defense service. 

14. Monitoring and Reporting. NSS space systems must be monitored over time to manage 
risk and to maintain authorizations to operate, due to the dynamic nature of risk factors. Timely 
and accurate reporting of threats, vulnerabilities, and warnings must be disseminated within the 
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government and with commercial partners as needed to ensure appropriate response and 
mitigations. Monitoring of NSS space systems is performed from operational, IA, system, and 
network perspectives. Reporting and monitoring from all of these perspectives are designed to 
accurately and completely determine the mission impact. 

a. Unauthorized use of links: Unauthorized attempts to access space platform links 
(also known as bandwidth piracy) should be analyzed across all links. At the discretion of the 
AO, the space platform operator must implement security controls to prevent, monitor, attribute, 
and report unauthorized bandwidth usage to the mission owner. 

b. Electro-magnetic interference (EMI): Departments/Agencies must establish 
capabilities and processes to support detecting, geolocating, reporting, and responding to EMI 
that impacts the ability of NSS space systems to carry out their missions. 

1) Technical controls to enable detection, geolocation, and response to EMI for new 
system developments must be considered during the system concept development phase. These 
high-level system requirements/capabilities must be developed by the cognizant requirements 
development entity during the system concept development phase. 

2) In order to assure availability to authorized users, the AO, mission owners, and 
operations centers must pre-coordinate to: 

a) Identify measures designed into the satellite system to detect, geo-locate, and 
resolve EMI events. 

b) Identify operational controls to address any deficiencies in the detection, 
geolocation, and resolution of EMI. 

c) Consider the use of capabilities external to the satellite system (such as 
terrestrial based Signals Intelligence (SIGINT) systems or overhead collection systems) to 
supplement the geolocation of EMI. 

3) Develop and implement procedures to summarize and report EMI. 

c. Information Security Continuous Monitoring (ISCM). NSS space organizations must 
implement a process to support ongoing monitoring of information security across the 
organization, consistent with NIST SP 800-137, Information Security Continuous Monitoring for 
Federal Information Systems and Organizations (Reference g). 

1) NSS space organizations must define a comprehensive ISCM strategy 
encompassing technology, processes, procedures, operating environments, and people. 

2) Program offices must develop an ISCM strategy for each NSS space system 
consistent with the organizational ISCM strategy. The system ISCM strategy must demonstrate 
the ability to continuously monitor the security automation domains (and the related security 
controls) from Reference g. 

3) The system ISCM strategy must leverage information provided by Cyberspace 
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Defense Service providers, as these providers are collecting, correlating, and analyzing security- 
related information from an enterprise- wide perspective, to include the sources and targets of 
attack/exploits, vulnerabilities across and specific to systems, and patches or upgrades necessary 
to thwart adversary efforts. 

d. Commercial Space System Services. 

1) If the Department/Agency requiring commercial services requires operations 
monitoring and control of those services, it must be identified in their contract language. 
Contract language must: 

a) Establish whether the vendor must provide a Network Operations Center 
(NOC) facility and an antenna in the space platform footprint to receive and monitor the signal. 

b) Establish whether the NOC must be staffed 24 hours per day, 7 days per week, 
and 365 days per year. 

c) Establish reporting procedures and parameters, to include: 

1 . Threshold for outages causing service interruption or degradation 

2. Reportable events (e.g., outages escalating to an event) 

3. Thresholds for when reporting must occur 

4. Report formats 

2) Areas Departments/Agencies must consider for IA monitoring over the contract 
life include: 

a) Ensure IA compliance monitoring is outlined in initial acquisitions and leases. 

b) Establish in initial acquisitions that vendors must monitor and report changes 
of their IA posture in writing and provide details of how the changes affect the IA posture. 

c) The AO must initially establish the security controls for acquisition or lease, 
which of those security controls must be monitored, the frequency of monitoring, and by whom. 

d) Determine acceptable tools vendors may use to monitor for, manage, and 
report events and the format in which these tools must report events. 



SECTION VI - DEFINITIONS 

15. Definitions are provided to clarify terms contained in this instruction, if they are not 
defined in Reference b or CNSSI No. 4009, National Information Assurance (IA) Glossary 
(Reference h). 
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SECTION VII - REFERENCES 



16. Future updates to referenced documents must be considered applicable to this 
implementation guidance. 



Enclosures: 

ANNEX A - DEFINITIONS 
ANNEX B - ACRONYMS 
ANNEX C - REFERENCES 

ANNEX D - PROGRAM PROTECTION PLAN (PPP) 

ANNEX E - BODY OF EVIDENCE (BOE) ARTIFACTS 

ANNEX F - TRANSMISSION SECURITY (TRANSEC) 

ANNEX G - COMMERCIAL LEASE 

ANNEX H - HOSTED PAYLOADS 

ANNEX I - FLIGHT TERMINATION SYSTEM (FTS) 

ANNEX J - CYBERSPACE DEFENSE SERVICES 
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ANNEX A 



DEFINITIONS 

1. Anti-Jam : The result of measures to resist attempts to interfere with communications 
reception. 

2. Anti-Signal Fingerprint : Result of measures used to resist attempts to uniquely identify a 
particular transmitter based on its signal parameters. 

3. Anti-Signal Spoof : Result of measures used to resist attempts to achieve imitative or 
manipulative communications deception based on signal parameters. 

4. Cover : Result of measures used to obfuscate message externals to resist traffic analysis. 

5. Hosted Payload : A payload carried and supported by a platform where acquisition and 
operation of the payload is under the authority of an organization different from the hosting 
platform. 

6. Host Platform : A space platform that carries and supports a payload where acquisition 
and operation of the platform is under the authority of an organization different from the hosted 
payload. 

7. Low Probability of Detection : Result of measures used to resist attempts by adversaries 
to recognize when a transmission is occurring. 

8. Low Probability of Intercept : Result of measures used to resist attempts by adversaries to 
analyze the parameters of a transmission to determine if it is a signal of interest. 

9. Low Probability of Positioning : Result of measures used to resist attempts by adversaries 
to determine the location of a particular transmitter. 

10. Program Protection Plan : A risk-based, comprehensive plan to protect critical program 
information and critical components associated with a program throughout the research, 
development, and acquisition phase. 

11. Traffic Flow Security : Result of measures used to conceal or obfuscate communication 
patterns. 
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ANNEX B 
ACRONYMS 



AO 


Authorizing Official 


BOE 


Body of Evidence 


CC 


Critical Component 


CDS 


Cross Domain Solution 


CNSS 


Committee on National Security Systems 


CNSSI 


Committee on National Security Systems Instruction 


CNSSP 


Committee on National Security Systems Policy 


COMSEC 


Communications Security 


CPI 


Critical Program Information 


EA 


Electronic Attack 


EMI 


Electro-magnetic Interference 


FTS 


Flight Termination System 


IA 


Information Assurance 


ISCM 


Information Security Continuous Monitoring 


IT 


Information Technology 


NIST 


National Institute of Standards and Technology 


NOC 


Network Operations Center 


NSA 


National Security Agency 


NSD 


National Security Directive 


NSS 


National Security System 


OPSEC 


Operations Security 
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OSI Open Systems Interconnection 

POA&M Plan of Action and Milestones 

PPP Program Protection Plan 

PPS Port, Protocol, and Service 

RMF Risk Management Framework 

SAR Security Assessment Report 

SCA Security Controls Assessor 

SCRM Supply Chain Risk Management 

SIGINT Signals Intelligence 

SP Special Publication 

SSP System Security Plan 

STP System TRANSEC Plan 

TRANSEC Transmission Security 

U.S. United States 
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ANNEX C 
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ANNEX D 



PROGRAM PROTECTION PLAN (PPP) 

1. Background: Many NSS space systems are developed in whole or in part on 
information systems maintained, controlled, and protected out of purview of the AO. 
Development often occurs in unclassified environments with little oversight or mandated 
protection. Subsequent classification of the information is difficult to assure, because it has 
been exposed to a high level of risk and potential for previous compromise. Even unclassified 
information must be protected due to sensitivity of aggregated information and because a 
compromise of the architecture, data flows, components, and configurations of NSS space 
systems may provide some advantage to the adversary. 

2. Critical components (CC) are or contain information and communications technology 
(including hardware, software, and firmware, whether custom, commercial, or otherwise 
developed) which delivers or protects mission critical functionality of a system or which, 
because of the system's design, may introduce vulnerability to the mission critical functions of 
an applicable system. 

3. Critical program information (CPI) are elements or components of a program in the 
research, development, and acquisition phase that, if compromised, could cause significant 
degradation in mission effectiveness; shorten the expected effective life of the system; reduce 
technological advantage; significantly alter program direction; or enable an adversary to defeat, 
counter, copy, or reverse engineer the technology or capability. CPI includes information about 
applications, capabilities, processes, and end-items; elements or components critical to a system 
or network mission effectiveness; or technology that would reduce the U.S. technological 
advantage if it came under foreign control. 

4. To reduce the potential for information compromise, CPI and CC must be 
protected at equivalent levels during development and operations. Items to consider, on the 
information systems used to develop NSS space systems, may include defensive cyberspace 
service providers, monitoring and reporting of information compromises, processes for 
controlling information access, SCRM, and residual risk posture. 

5. The PPP is used to develop tailored protection guidance for CPI and CC, and this 
guidance is disseminated and implemented throughout the program for which it is created. The 
layering and integration of the selected protection requirements documented in a PPP provide 
for the integration and synchronization of CPI and CC protection activities throughout the 
Department/Agency. Following are key elements of a PPP, which are tailored to meet program 
requirements: 

a. Technology and project description or system and program description with an 
emphasis on what is unique as the foundation for identifying CPI and CC. 
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b. List of CPI and CC to be protected in the program. This generally describes 
classified CPI in an unclassified manner and is not suitable for horizontal protection analysis 
(i.e., across programs) or the preparation of a counterintelligence assessment. 

c. Threats to CPI and CC: 

1) Internal and external threats 

2) Summary of threat data from the intelligence community 

d. Vulnerabilities of CPI and CC to identified threats 

e. Countermeasures: 

1) Security countermeasures (all disciplines, as appropriate) 

2) Counterintelligence support plan 

3) Anti-tamper annex 

4) OPSECplan 

5) System assurance 

6) Other countermeasures (unspecified) 

f. Technology assessment/control plan 

g. Classification guides 

h. Protection costs 

i. Follow-on support 
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ANNEX E 

BODY OF EVIDENCE (BOE) ARTIFACTS 

Below is a list of exemplar BOE artifacts, in addition to those identified in paragraph 6.g.l of 
this instruction. The list below is not all inclusive and may be tailored early in system 
development to assist program managers/information system owners in identifying artifacts 
necessary to show compliance with assigned security controls. Some systems (e.g., systems in 
sustainment) may not have all the artifacts listed below. For RMF and connection decision 
purposes, the list of artifacts appropriate for a system at various points in its life cycle (to include 
upgrades and changes to fielded systems) should be coordinated with the AO and the SCA. 

1 . Agreed Data Requirements List 

2. Clinger-Cohen Compliance Report 

3. Communications Security (COMSEC) Material Control Guide 

4. COMSEC Operational Security Doctrine 

5. Configuration Management Plan (developmental and operational) 

6. Conformance Test Plan 

7. Conformance Test Report 

8. Cross Domain Appendix 

9. Fail-Safe Design Analysis 

10. Incident Response Plan/Tactics, Technique and Procedures 

1 1 . Information Assurance Strategy 

12. Insider Threat Monitoring and Mitigation Strategy 

13. Interface Design Description 

14. System Key Management Plan (or Key Certificate Management Architecture) 

15. Operating Procedures 

16. Operational Requirements Document 

17. Patch Management Plan 

18. Penetration Test Plan 
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19. Program and Budget Documentation 

20. Program Protection Plan 

2 1 . Software Development Plan 

22. Software Installation Plan 

23. Software Test Plans/Procedures 

24. Software User's Manual 

25. System/Subsystem Detailed Design 

26. System/Subsystem Specification 

27. System TRANSEC Plan 

28. TEMPEST Control Plan 

29. TEMPEST Test Plan and Report 

30. Threat Studies and Analyses 

3 1 . Version Description Document 

32. Vulnerability Management Plan 

33. Contracts and agreements with developer/contractor related to security 

34. Results of developer/contractor tests and analysis related to security 
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ANNEX F 



TRANSMISSION SECURITY (TRANSEC) 

1. TRANSEC measures (as required by security controls) are necessary whenever mission 
requirements dictate the need to prevent interception, disruption of reception, communications 
deception, and/or derivation of intelligence by analysis of transmission characteristics such as 
signal parameters and message externals. At the highest level, there are two classes of threats 
TRANSEC measures address: 

a. SIGINT: SIGINT activities include communications intelligence, electronics 
intelligence, and foreign instrumentation intelligence. SIGINT efforts against space systems 
target transmissions from operations centers, mission/user terminals, and/or space platforms in 
order to defeat signal and transmitter confidentiality. SIGINT activities include scanning the 
electromagnetic spectrum to detect, locate, fingerprint the transmitter; intercept the message 
external information; and/or analyze traffic flow patterns. 

b. Electronic Attack (EA): Transmission of hostile signals (jamming) to interfere with 
the reception of legitimate signals, consume bandwidth in order to compete with legitimate 
signals (denial of service), and/or transmit signals intended to achieve imitative or manipulative 
communications deception based on signal parameters. The intentions of these EA efforts are to 
deny signal availability or defeat signal integrity. 

2. Implementation of the following measures, singularly or in combination, address threats 
to communication channels: 

a. Anti-Jam (also known as jam resistance) 

b. Anti-Signal Fingerprint 

c. Anti-Signal Spoof 

d. Cover 

e. Low Probability of Detection 

f. Low Probability of Interception 

g. Low Probability of Positioning 

h. Traffic Flow Security 

3. The STP includes: 

a. Description of all system communications links (type, missions supported, locations 
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of transmitters and receivers, etc.) 

b. For each link: 

1) Potential mission impact (low, moderate, or high) due to the loss of the link's 
confidentiality, integrity, and/or availability. 

2) TRANSEC measures required and specific techniques to achieve the level of 
robustness appropriate for system categorization defined in accordance with Reference d. 

c. List of validated threat intelligence and documents reviewed describing current and 
future threats over the lifetime of the system. 

d. Description and rationale for the system-level TRANSEC measures planned and/or 
implemented to mitigate relevant current and projected threats. 

e. Confirmation that the overall risk assessment addresses TRANSEC. 

f. Description of mission impact and alternate plans to support critical mission 
operations, if projected threats cannot be adequately countered. 

g. Details of planned cryptographic techniques or equipment supporting TRANSEC 
measures, NSA documentation approving the techniques and equipment, and an overview of the 
NSA-approved key management approach. 

h. Program schedule for TRANS EC -related activities. 

i. List of organizations consulted and/or required to provide TRANSEC advice, 
guidance, and/or approval as a function of the categorization (in accordance with Reference d) 
and TRANSEC techniques. Organizations the STP should consider include: 

1) NSA: Approve cryptographic techniques or devices needed to support 
TRANSEC measures. 

2) Threat Authorities (e.g., Defense Intelligence Agency, and the National Air and 
Space Intelligence Center): Provide intelligence data regarding adversarial capability and intent 
to execute a counterspace mission such as electronic attack, SIGINT, offensive cyber operations, 
command link intrusions, etc. 

3) Research Laboratories and/or Federally Funded Research and Development 
Centers: Assess the efficacy of a particular TRANSEC technique in addressing the threat and 
help assess of the residual risk. 

4. The STP for new system developments must be initiated during the system concept 
development phase. As mission requirements, concept of operations, system design, and threat 
knowledge mature, the STP must be reviewed, revised, and updated throughout the system 
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lifecycle along with other IA plans. 

a. The initial draft of the STP describing the key, high-level system TRANSEC 
requirements/capabilities needed must be developed by the cognizant requirements development 
entity during the system concept development phase. 

b. The system's mission owner and AO (or designee) must be afforded the opportunity 
to review the system concept, draft STP prior to subsequent system contract awards. 

c. After completion of the concept development phase and development of the initial 
STP draft, the system program office assumes STP ownership. 

d. The program office must provide the STP status and planned implementation for 
review at each major system milestone and design review. The program office must provide the 
STP to the AO in advance of each milestone review, allowing sufficient review time. 

e. The AO must review the latest version of the STP prior to issuing an authorization to 
operate. For some TRANSEC implementations, approval from certain external organizations (as 
identified in the STP) may be required prior to submitting the STP to the AO (reference 
paragraph 4.L above). 

f. The STP must be maintained and updated along with other high-level IA plans as 
necessary to maintain the AO's authorization to operate. 

5. The STP for space systems whose services are to be leased, purchased, or otherwise 
acquired for national security missions must be developed by the cognizant acquisition authority 
and mission owner and approved by the AO (or designee) prior to contract award or equivalent. 
An Annex to the STP will contain the TRANSEC-related contract language. The STP must be 
updated after contract award or equivalent, if acquired services require change, the mission or 
concept of operations changes, or if significant new threats or vulnerabilities become known that 
may impact TRANSEC needs. 
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ANNEX G 



COMMERCIAL LEASE 

1. Departments/ Agencies must determine the overall IA requirements and specific set of 
security controls most important to accomplishing their specific missions. Reference d and the 
Space Platform Overlay provide a starting point for identifying potential security controls for a 
commercial lease contract. Other security controls may be required beyond these. The controls 
will be applied and evaluated commensurate with the impact categorization identified in 
accordance with Reference d. Some areas to consider in selecting and tailoring the types of 
security controls for all components of a space system in the space, ground, user, or launch 
segments are any requirements in the lease associated with: 

a. Physical and logical protection of fixed or mobile terrestrial-based facilities (e.g., 
satellite control facilities and ground stations such as NOCs, Teleports, etc.). 

b. Continuity of operations for ground facilities. 

c. Processing, storing, transmitting and/or receiving classified, proprietary, or other 
types of data not approved for public release. 

d. Operations Security (OPSEC) measures to ensure anonymity of the 
Department/Agency from any of their third-party contractors. 

e. Periodic third-party validation of vendor facilities and personnel, and of security 
processes, procedures, controls, and configurations. 

2. If required by the mission owner, the Department/Agency must stipulate in the contract 
that "non-preemptible" service is required. This ensures the Department/Agency's service is 
contractually obligated to be provided for the entire duration of the lease and cannot be stopped 
and provided to some other customer or user, otherwise the vendor is in breach of the contract. 

3. The contract proposal evaluation plan may contain minimum threshold and any objective 
requirements as determined by the applicable AO and mission owner prior to releasing requests 
for proposal (or equivalent document). The evaluation plan may indicate preference is given to 
vendors who can meet threshold requirements and some established level of or all the objective 
IA requirements. 

4. The Federal Acquisition Regulations and the Defense Acquisition Regulations provide 
the requirements, processes, and sample documentation needed to process a commercial lease 
contract. 
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ANNEX H 



HOSTED PAYLOADS 



1. Typically, hosted payloads and hosting platforms conduct acquisition, design, and 
development with differing levels of security requirements and controls. When non-NSS 
organizations (e.g. commercial, U.S. civil, or foreign) develop spacecraft and host an NSS 
payload, security risks to the NSS-payload are greater due to a lack of NSS organizational insight 
and control of the host platform's design, manufacture, and operation. Conversely, when 
organizations within the NSS community acquire and control both the payload and spacecraft, 
the requisite security controls are more likely to be already implemented. 

2. The following are requirements the government hosted payload organization addresses in 
IA strategies, SSPs, contracts, and memoranda of agreement, when using hosting platforms: 

a. Process and procedures detailing how and when the hosting platform and hosted 
payload organizations share IA design/assurance information and determine how to share 
implemented IA capabilities. 

b. Negotiated hosting platform security controls and related design changes necessary to 
mitigate serious risks to the hosted payload mission. 

c. Security-related interface requirements. 

d. Pre- and post-launch tests to verify IA functionality and status. 

e. IA requirements as an integral part of design reviews and decisions. 

f. Identification and mitigation of significant IA risks associated with the payload's and 
hosting platform's external interfaces and communications links. 

g. Development, review, and approval of a comprehensive IA architecture describing: 



1) Physical and/or logical separation of payload mission data from the host platform. 

2) Payload command and control data processing. 

3) Implementation of payload and platform COMSEC and TRANSEC. 

4) Data transmission to/from each communication link. 

5) Information flows between host platform and payload's space and ground 



segments. 



6) 



CDS requirements. 
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h. Measures used to protect proprietary information (domestic or foreign), national 
security information, U.S. government information not approved for public release, and foreign 
government information. 

i. Procedures addressing foreign acquisition requirements as identified in applicable 
statutory and regulatory documents. 

j. Operational procedures for identifying, responding to, and recovering from attacks, 
anomalies, emergencies, and other security-impacting events. 

k. Potential incentives or preferences for commercial entities implementing host space 
platforms fully or partially compliant with CNSS IA requirements and meeting the hosted 
payload's protection requirements. 
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ANNEX I 



FLIGHT TERMINATION SYSTEM (FTS) 

1. Flight termination includes actions to end the flight of an errant aerospace vehicle posing 
a threat to public safety or that must be prevented from leaving controlled areas to protect 
sensitive information or technology. FTS must be designed, built, and operated to reliably 
terminate errant aerospace vehicles and to prevent unwanted termination of aerospace vehicles. 

2. FTS fall into three categories: commanded, autonomous, and hybrid. 

a. Commanded: In a commanded system, the decision to terminate a vehicle and the 
associated commands originate from a source outside the aerospace vehicle. Each system and 
link must be examined to determine the requirement for security controls. Reference b requires 
use of NSA-approved cryptography for launch vehicles using remotely-controlled FTS. FTS 
implementations lacking NSA-approved cryptography (e.g., Inter Range Instrumentation Group) 
are not authorized for the launch of spacecraft falling under the scope of Reference b. 

b. Autonomous: Autonomous systems include many of the same components as 
commanded systems; however, the decision to terminate flight is made by the aerospace vehicle. 
Procedures must be in place to ensure the software and/or firmware remains unmodified from the 
reviewed and approved version. Confidentiality, integrity, and availability of links connecting 
these components must be examined to ensure adequate safety and mission assurance is 
provided. Use of Precise Positioning Service is required for all launch vehicles delivering NSS. 

c. Hybrid: Hybrid FTS combine features of both commanded and autonomous systems. 
The security of hybrid FTS must meet the minimum requirements for both commanded and 
autonomous systems. 

3. Nearly every link requires integrity and availability controls, but careful consideration to 
system and link availability must be given to systems that allow the aerospace vehicle to 
continue or terminate based on a lack of inputs needed to make those decisions. Many FTS 
include safeing mechanisms that block the execution of flight termination prior to leaving the 
launch complex or after the point where the vehicle can no longer pose a threat to safety or leave 
the controlled area. These features can be effective in reducing risks from adversary jamming 
and spoofing of data sources or command links early or late in the aerospace vehicles flight. 
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ANNEX J 



CYBERSPACE DEFENSE SERVICES 

Cyberspace defense services are described as follows: 

1. Prepare: organize, develop processes and procedures, train, and equip (select and deploy) 

2. Protect: maintain security posture, protect data, prevent malware, prevent unauthorized 
access, and contain or eradicate an attack 

3. Detect: monitor and detect unauthorized or malicious activity 

4. Analyze: determine if attacked (i.e., are network problems a result of malicious actions 
or benign actions/equipment failures), characterize attack (e.g., determine if a network 
outage is due to a computer attack and of what type or due to jamming of a 
communications link carrying the network), identify impacted systems and assets, 
perform damage assessments, and report incidents 

5. Respond: develop course/s of action, implement changes to counter attack or mitigate, 
determine residual risk, and incident handling/collaboration 

6. Assess and Adjust: assess services effectiveness and residual risk, implement changes, 
and conduct evaluations and assessments 
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